packages/vue/src/tooltip/src/index.ts (1)

3-10: Dynamic template selection implemented

The code now supports dynamic selection between PC and mobile-first tooltip components, replacing the previous virtual template import mechanism. This provides more flexibility for different UI requirements.

Consider translating the Chinese comment "新PC, 老 MF" to English for better international team collaboration.

-const template = (mode) => (mode === 'pc' ? TooltipPc : TooltipMf) // 新PC, 老 MF
+const template = (mode) => (mode === 'pc' ? TooltipPc : TooltipMf) // New PC, old Mobile-First

packages/renderless/src/tooltip/new-vue.ts (1)

73-74: Remove empty teardown hook

onUnmounted(() => {}) is a no-op. Either call doDestroy() to clean Popper
resources or delete the hook to avoid dead code.

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

packages/vue/src/tooltip/src/tooltip.vue (1)

7-8: ⚠️ Potential issue

Fix the accessibility attribute spelling

The attribute :aria-describeby is misspelled and should be :aria-describedby. Screen readers won't recognize the current attribute name, which breaks accessibility.

-:aria-describeby="state.tooltipId"
+:aria-describedby="state.tooltipId"

packages/vue/src/tooltip/src/tooltip.vue (7)

136-136: Improve array inclusion check

Using the bitwise NOT operator with indexOf is an outdated pattern. The includes() method provides a more readable and modern approach, as already used in line 62.

-validator: (value: string) => Boolean(~['normal', 'warning', 'error', 'info', 'success'].indexOf(value))
+validator: (value: string) => ['normal', 'warning', 'error', 'info', 'success'].includes(value)

---

87-87: Add default value for content prop

The content prop lacks a default value, which could lead to unexpected rendering issues. Consider adding a default empty string.

-content: { type: [String, Object] },
+content: { 
+  type: [String, Object],
+  default: () => ''
+},

---

101-102: Add default values for boolean props

The manual and modelValue props don't have default values. It's a good practice to explicitly define defaults for boolean props.

-manual: { type: Boolean },
-modelValue: { type: Boolean },
+manual: { 
+  type: Boolean,
+  default: () => false 
+},
+modelValue: { 
+  type: Boolean,
+  default: () => false 
+},

---

121-123: Define type and default for reference and popper props

The reference and popper props are missing type definitions and default values, making their expected usage unclear.

-reference: {},
-popper: {},
+reference: { 
+  type: [Object, String],
+  default: () => null
+},
+popper: { 
+  type: [Object, String],
+  default: () => null
+},

---

19-19: Extract complex class binding to a computed property

The class binding combines multiple conditions and is difficult to read. Consider extracting it to a computed property for better maintainability.

// In the template
-:class="['is-' + (type || effect || 'dark'), popperClass, state.showContent ? 'tiny-tooltip__show-tips' : '']"
+:class="popperClassNames"

// In the script, add to the renderless function or setup return
+computed: {
+  popperClassNames() {
+    return [
+      `is-${this.type || this.effect || 'dark'}`,
+      this.popperClass,
+      this.state.showContent ? 'tiny-tooltip__show-tips' : ''
+    ]
+  }
+}

---

63-67: Improve prop documentation with better comments

Several props have unclear purpose, indicated by Chinese comments or minimal documentation. Consider adding comprehensive JSDoc comments to explain each prop's purpose, expected values, and usage examples.

Example for adjustArrow:

-// 原来未暴露的属性, 自动传入vue-popper
 adjustArrow: {
   type: Boolean,
   default: () => false
 },
+/**
+ * @description Whether to automatically adjust the arrow position
+ * @default false
+ */
+adjustArrow: {
+  type: Boolean,
+  default: () => false
+},

Also applies to: 73-77, 78-82, 120-123, 142-146

---

20-20: Consider using computed properties for style bindings

Direct style bindings in templates are less maintainable and can make the template harder to read. Consider extracting these to computed properties.

// In the template
-:style="{ ['max-width']: state.tipsMaxWidth }"
+:style="popperStyle"

// In the script, add to the renderless function or setup return
+computed: {
+  popperStyle() {
+    return { 'max-width': this.state.tipsMaxWidth }
+  }
+}

// Same approach for the content wrapper style

Also applies to: 29-29

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

examples/sites/demos/pc/app/tooltip/control.spec.js (1)

1-46: 💡 Verification agent

🧩 Analysis chain

Potential test reliability issues with short timeouts.

The test uses very short timeouts (20ms) in several places which could lead to flaky tests, especially in slower environments or during CI/CD pipeline execution.

Consider increasing the timeout values to more reasonable durations (e.g., 100-300ms) or better yet, use Playwright's built-in wait mechanisms like waitForSelector or waitForTimeout with the default timeout values.

---

🏁 Script executed:

#!/bin/bash
# Count the number of short timeouts in tooltip tests
echo "Checking for potentially flaky timeouts in tooltip tests..."
rg "waitForTimeout\(\s*\d{1,2}\s*\)" examples/sites/demos/pc/app/tooltip/ -l | xargs -I {} echo "Found short timeout in: {}"

Length of output: 801

---

Increase timeouts or leverage Playwright’s built-in wait mechanisms in tooltip tests

We’ve identified waitForTimeout(20) calls across multiple tooltip spec files, which are prone to flakiness on slower CI agents or under load. Instead of arbitrary short sleeps, prefer explicit waits or increase timeouts to more realistic values (100–300 ms) when you really need them.

Affected files:

• examples/sites/demos/pc/app/tooltip/control.spec.js
• examples/sites/demos/pc/app/tooltip/custom-popper.spec.js
• examples/sites/demos/pc/app/tooltip/content-max-height.spec.js
• examples/sites/demos/pc/app/tooltip/theme.spec.js
• examples/sites/demos/pc/app/tooltip/offset.spec.js
• examples/sites/demos/pc/app/tooltip/delay.spec.js
• examples/sites/demos/pc/app/tooltip/content.spec.js

Recommendations:

• Replace await page.waitForTimeout(20) with one of:
  • await page.waitForSelector('<selector>', { state: 'visible' })
  • await expect(locator).toBeVisible({ timeout: 500 })
• If you must use waitForTimeout, bump it to at least 100–300 ms, or tie it to a variable/config so it can adapt in slower environments.
• Remove redundant sleeps after actions that already have built-in waiting (e.g., .click(), .hover(), or expect assertions).

This will make your tooltip tests more robust and less prone to intermittent failures.

packages/renderless/src/tooltip/new-vue.ts (2)

5-5: ⚠️ Potential issue

toggleShow is missing from the exported API list

The method toggleShow is used internally (line 40) but not included in the exported API array. This will make it inaccessible to components that rely on this function.

-export const api = ['state', 'handlePopEvent', 'handleRefEvent']
+export const api = ['state', 'handlePopEvent', 'handleRefEvent', 'toggleShow']

---

29-37: 🛠️ Refactor suggestion

Initialize state with default values instead of overwriting reactive properties

Setting showPopper.value = false directly and then including it in the reactive state could lead to reactivity issues. This approach risks breaking the reactive connection with PopperJS.

-showPopper.value = false // 初始为false
const state = reactive({
-  showPopper,
+  showPopper: false, // Initialize directly in the state object
  popperElm,
  referenceElm,
  tooltipId: guid('tiny-tooltip-', 4),
  showContent: inject('showContent', null),
  tipsMaxWidth: inject('tips-max-width', null)
})

packages/vue/src/tooltip/src/clickoutside.ts (1)

36-56: Use optional chaining for potential null/undefined values

The function accesses properties that might be undefined without using optional chaining, which could lead to runtime errors.

const createDocumentHandler = (el, binding, vnode) =>
  function (mouseup = {}, mousedown = {}) {
-   let popperElm = vnode.context.popperElm || (vnode.context.state && vnode.context.state.popperElm)
+   let popperElm = vnode.context?.popperElm || (vnode.context?.state?.popperElm)

    if (
      !mouseup?.target ||
      !mousedown?.target ||
      el.contains(mouseup.target) ||
      el.contains(mousedown.target) ||
      el === mouseup.target ||
      (popperElm && (popperElm.contains(mouseup.target) || popperElm.contains(mousedown.target)))
    ) {
      return
    }

    if (binding.expression && el[nameSpace].methodName && vnode.context[el[nameSpace].methodName]) {
      vnode.context[el[nameSpace].methodName]()
    } else {
-     el[nameSpace].bindingFn && el[nameSpace].bindingFn()
+     el[nameSpace]?.bindingFn?.()
    }
  }

🧰 Tools

🪛 Biome (1.9.4)

[error] 38-38: Change to an optional chain.

Unsafe fix: Change to an optional chain.

(lint/complexity/useOptionalChain)

---

[error] 54-54: Change to an optional chain.

Unsafe fix: Change to an optional chain.

(lint/complexity/useOptionalChain)

examples/sites/demos/pc/app/tooltip/control.spec.js (1)

12-15: Improved selector specificity for tooltip elements.

The change from text-based selectors to more precise class-based selectors with index targeting improves test stability and clarity. Each tooltip element now has a specific locator that directly corresponds to different tooltip modes.

Consider using more descriptive variable names like intelligentLongTooltip, intelligentShortTooltip, etc. instead of content1, content2, etc. to improve readability and make the test more self-documenting.

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro